allow marking objects as without opening hours sign [prepare for a tag replacement] #1118
Conversation
|
Being unable to collect information != No signs with these information. E.g. it could be access restricted, not thgere any more, etc. All things, which would require the user to select the "add note" instead. So i'd suggest to reword the warning message to make that clear. The menu item is quite fine, IMHO. |
Do you have any idea what would fit? Maybe back to earlier "Are you sure that there is no sign with opening hours info?" |
|
Yes, that's a bit clearer e.g. |
app/src/main/res/values/strings.xml
Outdated
| @@ -453,6 +453,9 @@ Otherwise, you can download another keyboard in the app store. Popular keyboards | |||
| <string name="invalidate_confirmation">Invalidate</string> | |||
| <string name="invalidation_dialog_message">Invalidating the cache causes the quests to be updated next time they are downloaded. The quest cache is invalidated automatically after one week and immediately when a quest you solved turns out to be already answered by someone else.</string> | |||
| <string name="quest_openingHours_emptyAnswer">You need to describe what is on the sign. If there is no sign, you should ask for the opening hours inside.</string> | |||
| <string name="quest_openingHours_no_sign">Opening hours are unknown</string> | |||
There was a problem hiding this comment.
Actually, it should say "No opening hours sign"
There was a problem hiding this comment.
I wanted to avoid discouraging people from asking about opening hours. People should use this option only when there is no opening hours sign and there are unable/unwilling to collect it by other means (usually asking worker inside).
There was a problem hiding this comment.
But this is exactly what the opening_hours:signed tag is about.
There was a problem hiding this comment.
I agree but I think that there are three situations
- opening hours are signed (tag
opening_hours) - opening hours are not signed, one is willing and able to collect them anyway (maybe shop is without customers and one is able to ask shopkeeper, maybe one has a local knowledge, maybe...) -> tagging
opening_hoursand taggingopening_hours:signed=no is correct but taggingopening_hoursis preferable - opening hours are unsigned, one is unable or unwilling to collect the opening hours data -> tag
opening_hours:signed
For the second case I wanted to avoid tagging opening_hours:signed but I may change that if you are sure.
There was a problem hiding this comment.
There was a problem hiding this comment.
Yes, please do.
For the second case, users are slightly encouraged to collect them anyway because the not-signed answer is hidden in the other answers submenu
Which one? I would be happy to make PR but I am not sure for which quest it would be useful. |
|
|
|
OK, I will make it (after making final interface decision here in discussion above). |
matkoniecz
changed the title
matkoniecz
changed the title
matkoniecz
changed the title
I think that given that this change are supposed to be added together I will add it to this PR. |
|
I wonder what should be done with My current plan based on https://taginfo.openstreetmap.org/keys/note%3Acollection_times#values is to drop support for this tag as part of the PR and close to release retag it (to collection_times:signed or collection_times, depending on its content) |
matkoniecz
changed the title
matkoniecz
force-pushed
the
unsigned_opening_hours
branch
from
1ab9a46 to
b03b174
Compare
|
I agree, dropping support would be fine, and changing the already existing It is by the way super convenient for me that you put the current status in the title 👍 |
Great! I worried a bit that each title change may send notifications/mail/whatever and I was not sure is it a good idea (I was doing it to avoid getting lost in a stack of PRs). Now I can stop worrying :) |
matkoniecz
changed the title
# Conflicts: # app/src/main/res/values/strings.xml
|
You already dropped support for |
westnordost
changed the title
westnordost
changed the title
|
done, tested. |
|
Sorry, I had no time recently - and thanks for finishing this! |
fixes #1076